XWIKI-23830: Only display features in the editor when the backend supports it#5337
XWIKI-23830: Only display features in the editor when the backend supports it#5337ClementEXWiki wants to merge 8 commits intoxwiki:masterfrom
Conversation
ClementEXWiki
force-pushed
the
feat/syntaxes-config
branch
from
77febe6 to
8cc405d
Compare
| /** | ||
| * List of supported syntaxes, along with their configuration | ||
| * | ||
| * @since 18.1.0RC1 |
| designSystem: string, | ||
| offline: boolean, | ||
| editor: string, | ||
| syntaxes: SyntaxConfig[], |
There was a problem hiding this comment.
As already mentioned, api should only be touched to remove things out of it. We never want to make it grow.
Why do you need to add new properties here?
There was a problem hiding this comment.
How would a specific backend register its supported syntaxes?
There was a problem hiding this comment.
By registering a component with a specific role and name, then a lookup by the role and name.
Where the name is the registered syntax configuration.
There was a problem hiding this comment.
Should the package path be [...]/core/syntaxes/syntaxes-config?
There was a problem hiding this comment.
It would seem weird that the platform name of the package doesn't appear in the path
| /** | ||
| * List of supported syntaxes, along with their configuration | ||
| * | ||
| * @since 18.2.0RC1 |
There was a problem hiding this comment.
18.2.0RC1 was released a few hours ago ;)
| * 02110-1301 USA, or see the FSF site: http://www.fsf.org. | ||
| */ | ||
|
|
||
| import { generateConfig } from "../../../vite.config"; |
There was a problem hiding this comment.
You can now use @xwiki/platform-tool-viteconfig (since 18.2.0RC1) instead of relying on relative paths.
The same is also true for tsconfig that can now be imported from @xwiki/platform-tool-tsconfig
There was a problem hiding this comment.
I wasn't aware of that, thanks :)
I updated the code.
| expect(overrideFnCalledWithUrl).toBe(SMALL_IMG_DATA_URL); | ||
| }); | ||
|
|
||
| test("Whitelisted syntax features should be available", async ({ mount }) => { |
There was a problem hiding this comment.
WDYT of using allow/deny lists instead of black/white lists?
There was a problem hiding this comment.
It seems clearer to me to use whitelist and blacklist as they convey the meaning in a clearer way IMO. Everything not in a whitelist is denied, everything not in a blacklist is allowed.
There was a problem hiding this comment.
Well to be clear the words black and white are badly connotated and allow/deny have clear and similar meanings. Therefore, we tend to use allow/deny in the code base. So it's better to avoid black/white to stay uniform with the rest of the code.
There was a problem hiding this comment.
That connotation is a good point indeed. I updated the PR.
| query, | ||
| ); | ||
|
|
||
| // NOTE: there is no "clean" way to filter these elements as of now, so we rely on their hardcoded title instead |
There was a problem hiding this comment.
Is it working with a local different than english?
There was a problem hiding this comment.
Good catch! Fixed it.
2 participants
Jira URL
https://jira.xwiki.org/browse/XWIKI-23830
Changes
Description
Clarifications
Screenshots & Video
N/A
Executed Tests
Expected merging strategy
*